上一篇文章，我們替這個系列畫出清楚的範圍：要打造的是一個以繁體中文 Markdown 技術文件為知識來源，能夠回答技術問題、引用相關內容，並在資料不足時拒答的 RAG 知識助理。今天在準備文件與設計搜尋流程之前，還需要先理解另一個核心問題：LLM 到底知道什麼？

這個問題看似簡單，實際上卻很容易產生誤解。當我們說「模型知道 Spring Boot」或「模型知道某個框架的用法」時，這裡的知道並不等同於人類查閱文件後所理解的知道。LLM 並沒有一個可以直接打開、逐條查詢的知識目錄，它是從大量文字中學習語言模式與概念關聯，再根據目前收到的上下文，產生最可能接續的文字。

因此，模型能寫出看似專業的說明，不代表它正在讀取某份官方文件；模型能回答問題，也不代表它知道答案的來源。理解這個差異，會影響我們後面如何準備資料、設計 Prompt，以及為什麼需要在模型之外建立 RAG 的搜尋流程。

模型所謂的「知識」從哪裡來？

LLM 的知識主要來自訓練階段。模型會在大量文字資料上學習，逐步建立詞語、句子、概念與上下文之間的關聯。它不只是記住某些句子，也會學習一個概念通常如何被描述、兩個概念可能有什麼關係，以及特定問題後面通常會出現什麼樣的回答。

但這些內容最後會被壓縮進模型參數中，而不是保留成一個可以逐頁翻閱的文件庫。當我們問模型「什麼是 RAG」時，它會根據訓練過程中學到的語言模式組織答案；當我們詢問很新的函式或剛改版的設定方式時，它也可能依照名稱與相似概念進行推測。這就是為什麼模型即使沒有真正看過某份文件，仍然可能產生語氣完整的答案。

這種能力是 LLM 強大的地方，也是它容易產生幻覺的原因。模型很擅長產生「像答案的文字」，但不會自動替每個句子附上來源，也不一定能分辨自己是在回憶、推論，還是在猜測。對需要追溯依據的技術知識助理來說，就必須透過系統設計補足這個限制。

Token 不是單純的字數

討論 LLM 的上下文之前，必須先理解 Token。Token 是模型處理文字時使用的基本單位，但它不一定等於一個中文字、一個英文單字或一個完整句子。實際切分方式會依模型使用的 Tokenizer 而不同，中文、英文、標點符號、數字與程式碼也可能產生不同數量的 Token。

一段中文技術說明可能同時包含中文句子、英文套件名稱、版本號、路徑與程式碼符號。以「使用 SecurityFilterChain 保護 /api/** 底下的路徑」這句話為例，人眼看到的是一句話，Tokenizer 看到的卻是另一回事：中文部分通常一到兩個字就對應一個 Token，SecurityFilterChain 這種駝峰式命名可能被拆成 Security、Filter、Chain 幾個子詞，/api/** 則變成斜線與星號組成的片段。同一句話換一個模型的 Tokenizer，切法與總數都可能不同。因此，我們不能只用字數估算 Prompt 大小，也不能假設所有模型對同一段文字會產生相同的 Token 數量。

Token 會影響上下文容量、處理延遲與使用成本。當我們把使用者問題、對話歷史、搜尋到的文件片段與回答規則放進同一個請求時，真正消耗的是這些內容被 Tokenizer 切分後的總數。文件越長、歷史越多、程式碼越複雜，消耗的 Token 就可能越快增加。這也是後面需要做文件切分的原因：在保留語意完整性的同時，控制片段大小，讓搜尋結果能放進上下文，也留下產生回答的空間。

Context 是模型這一次能看到的內容

Context 通常翻譯為上下文，可以理解成模型在這一次請求中能讀到的所有內容。它可能包含系統指令、使用者問題、對話歷史、RAG 搜尋結果，以及我們要求模型遵守的回答格式。模型會根據這些內容產生當下的回答，但 Context 不等於模型永久記住了這些資料。

當我們在一次對話中把文件貼給模型，它可以在這次請求中參考文件；下一次重新開始請求時，如果沒有再次提供，模型不一定還能使用那份資料。即使介面看起來像模型記得前面的對話，實際上通常也是應用程式把部分歷史訊息重新放回新的 Context 中。

每個模型或服務都有自己的上下文限制。當輸入內容加上預計產生的輸出超過限制時，請求可能失敗、內容可能被截斷，或應用程式必須刪除一部分歷史訊息。即使沒有超過硬性上限，把太多不相關的文件交給模型，也可能讓重要內容被淹沒，降低回答品質。

因此，「把整個知識庫都塞進 Prompt」通常不是好方法。文件越多，成本與延遲越高；資料越雜，模型越難判斷哪些內容和問題相關。RAG 的 Retrieval 部分，正是要在大量文件中先找到少量且相關的內容，再交給 Generation 部分產生回答。

訓練資料、Context 與知識庫的差別

可以把 LLM 接觸到的資訊分成三個層次。第一個是訓練資料，它在模型建立時影響模型參數，不會因為我們今天新增一份筆記就立刻改變。第二個是 Context，也就是這次請求中實際提供給模型的文字，只對目前的生成流程有效。第三個是外部知識庫，它由應用程式管理，可以新增、刪除、更新與追蹤來源。

RAG 的設計，就是把第三層的知識庫內容，經過搜尋後放進第二層的 Context，讓模型在回答時使用較新、較專門的資料。模型不需要因為每次文件更新就重新訓練；我們需要做的是讓系統找到適合的文件，並以清楚的方式交給模型。

這也說明了 RAG 和 Fine-tuning 的差異。Fine-tuning 主要是調整模型的行為、格式或特定任務能力；RAG 則是把外部資料帶進當下的上下文。面對會持續更新的技術知識庫時，先設計可更新、可追溯的檢索流程，通常比把所有文件內容硬塞進模型更容易維護。

這些限制如何影響本系列？

今天的內容會直接影響接下來幾篇文章。既然 Token 不是單純的字數，Day 4 在設計知識庫時就必須保留文件標題、來源與版本等資訊；Day 5 處理繁體中文文字時，要注意清理內容不能破壞專有名詞與程式碼；Day 6 討論 Chunk 時，則要在語意完整、搜尋精準與上下文容量之間做取捨。

同樣地，RAG 的目標不是讓模型讀完所有文件，而是讓它在每個問題中取得足夠且相關的資料。後續的關鍵字搜尋、Embedding 與向量搜尋，都是為了回答同一個問題：面對使用者的問題，知識庫中哪幾段內容最值得交給模型？

如果忽略 Token 與 Context 的限制，可能會得到一個「資料很多但回答不穩定」的系統；如果只注意模型能力，卻沒有管理來源與文件範圍，就很難判斷回答到底是根據文件還是模型猜測。這也是本系列選擇從 NLP 與資訊檢索開始的原因：先把資料處理好，再讓模型負責它最擅長的語言生成。

結語

今天我們沒有建立向量資料庫，也沒有急著呼叫 LLM API，而是先釐清三個限制：模型參數中的知識不是可直接查詢的文件庫；Token 不是單純的字數；Context 是模型這一次能看到的內容，而且有容量與品質上的限制。

理解這些差異之後，RAG 的角色就變得清楚了。它不是用來把模型變得無所不知，而是把指定知識庫中與問題相關的內容，在正確的時間放進模型上下文，讓回答有機會建立在可追溯的資料上。

下一篇，我們會開始建立知識庫，決定 Markdown 文件要如何保存標題、來源、版本、主題與正文，讓後續的文字清理、文件切分與搜尋都有一致的資料基礎。